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Abstract 

Statically typed functional programming languages usually employ a ver¬ 
sion of the Hindley-Milner type system extended with ad-hoc polymorphism. 
When the type checker detects an error, it has to report it to the programmer, 
to help in fixing the bug. However, usage of algorithms W and M, commonly 
used to type-check languages with Hindley-Milner type systems, can result in 
cryptic error messages. We argue that the holistic nature of these algorithms 
is a cause of this. 

Next, we describe a type checking algorithm originally presented by Olaf 
Chitil in 2001, that, by its compositional nature, claims to produce error mes¬ 
sages that are more suitable for human processing — a property that type 
systems for imperative programming languages usually have. The main part 
of the thesis is extending the compositional algorithm for languages support¬ 
ing ad-hoc polymorphism. A proof of concept implementation is presented 
for the Haskell 98 programming language, interfacing the Glasgow Haskell 
Compiler. 

In conclusion, we present this implementation and ideas for future work. 



For Her, the supportive, Him, the ever curious, and Her, my partner in crime. 
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Introduction 


Software keeps growing larger and more complex, making it harder for us 
humans to understand programs enough to be able to reason about them. 
On the other hand, the field of software engineering is many decades old by 
now, and it's not unreasonable to expect of it the kind of maturity necessary 
to build large systems without it collapsing under its own complexity. 

On one end of the validation spectrum, we have formal methods, which 
use mathematical logic to prove program correctness. For example, the B 
method[ 1] uses the Hoare-Dijkstra model[2, 3] of predicate transformations 
to ensure that the resulting program meets its specification. However, writ¬ 
ing automatically verifiable proofs is an art in itself, requiring intellectual re¬ 
sources that are simply not available for most software development projects. 

To make software development practical in the real world, a division of 
labour is applied to verification: some program properties are expressed in a 
machine-readable way and can thus be enforced by a compiler, while others 
are checked by humans using pen and paper proofs or good old hand-waving. 
Static typing provides an old and tried way of using so-called type checkers 
for ensuring program properties, and various type systems correspond to 
different levels of formalness. Milner's slogan "Well-typed programs don't 
go wrong" [4] is true in general insofar as "rightness" can be expressed in the 
given type system, as stated formally by the Curry-Howard isomorphism[5]. 

The other straightforward way to try attacking increasing software com¬ 
plexity is breaking programs up into manageable chunks. For this approach 
to work, the programming language must be so that these parts can be com¬ 
posed into ever larger systems, while also giving a practical way to combine 
the results of analysing the individual chunks. Obviously, the success of this 
approach is greatly determined by the ways possible for a given part to affect 
other parts. 

The recent emergence of statically typed, pure functional programming 
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languages is explained in part because they suit these two approaches so 
well. Their type systems are usually expressive enough to encode meaningful 
program properties, and referential transparency[6] assures a lack of non¬ 
local effects, thus enabling reasonings about parts of programs to be easily 
elevated to reasonings about the whole of the program. 

But there is a price to pay for expressive type systems, and that price comes 
in the form of the mental capacity needed to use type checkers. Understand¬ 
ing the typing constraints in a dependently-typed functional language [7] like 
Agda[ 8], Coq[ 9] or Epigram[ 10] is so complicated that interactive tools have 
to be used to write well-typed programs. Mainstream functional program¬ 
ming languages like Haskell[ 11] or Clean[ 12] use a somewhat less expressive 
type system based on several extensions to the Hindley-Milner type system. 
One great advantage of these type systems is that they admit not just type 
checking, but also type inference. 

Users of these programming languages have all encountered error mes¬ 
sages from the type checker, and it is a well-known problem that these error 
messages can often be cryptic. Helium[13] is an implementation of the Haskell 
language addressing these problems by various heuristics[14]. 

One explanation of the difficulty of understanding type errors is that these 
type systems yield typing constraints that are non-compositional in the sense 
that the inferred type of a given expression is not just a function of its subex¬ 
pressions, but is also influenced by the super-expression it appears in. In 
2001, a paper by Olaf Chitil [15] presented a compositional approach to typ¬ 
ing expressions in a Hindley-Milner-like type system. 

In this thesis, we present an extension to the system described in Chi- 
til's paper that allows for ad-hoc polymorphism, a feature extensively used 
in Haskell[16]. We have implemented this type system on top of the Glas¬ 
gow Haskell Compiler[17], and the resulting type checker supports most 
of Haskell 98. The implementation is available under the BSD license at 
http://gergo.erdi.hu/projects/tandoori/. 
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Notations 


Inference rule systems 


We will define and examine a number of inference systems. Here, an inference 
system S is understood to be a collection of inference rules that are given in 
the form 


Statement P 
Statement Q 


(Rule) 


where Rule is the name of the rule that indicates, given the statement P, that 
the statement Q also holds. A statement R is then inferable in S if there is a 
suitable tree of inference rule applications. 

Rules can be axioms, meaning the P part is missing. Not all axioms are 
given in inference rule form: true statements that are outside the scope of 
the examined system are understood to be implicitly inferable. For example, 
when discussing type systems, we do not present a formal treatment of ZF 
set theory but use predicates like x e X freely. 

Rules can also be rule schemas that contain variables. The domain of 
a variable is determined by its name and typesetting (see next section); for 
example, the rule schema 


Tha 


(TyVar) 


defines inference rules for all type variables a. 


Environments 

Some inferable statements are about certain properties that follow from some 
environment or context. In these cases, we will write 

nh p 
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for these statements, where II is the context and P is some other statement 
that follows (i.e. inferable) in that context. 

Some statements are more about the generation of environments. If it 
makes more sense to think of a statement as "the property P holds, and also 
yields the environment II", we will instead write 

PHIL 

In some cases, there is both a context and a resulting environment for 
some property P. In these cases, the above notations are combined into 

n h p h e. 

Symbols and letters 

Most of the symbols and functions used throughout the thesis should be ei¬ 
ther straightforward or defined at its first occurrence. In particular, 

• dom / gives the domain of the function or finite mapping /, 

• vars r is the set of all type variables occurring in r. 

The following table shows the typographical conventions used: 


Roman typeface 

Functions 

dom 

Boldface 

Elements of expression syntax 

let... in .. 

Slanted typeface 

Type systems 

HM,C 


Variables 


Calligraphic typeface 

Algorithms 

W 

Small capital typeface 

Inference rules 

Abs 


(Type) constructors 

TRUE 

Greek small letters 

Elements of type systems 

t, a, 6 

Greek capitals 

Environments 

t, r, a, e 

Overline 

List/vector 

r 
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1. The typed lambda calculus 


In this chapter, we present a well-known type system for the lambda calculus. 
It is described here because several notations and customs are widespread 
and thus it is important to present the exact formulation that we'll use. The 
opportunity is also used to review some of the basic properties of the Hindley- 
Milner type system. 

1.1 The formal language A 

The variant of the lambda calculus that we'll explore is lambda calculus with 
algebraic datatypes, constructors and pattern matching. Its syntax is pre¬ 
sented in figure 1.1. Note that in this and later presentations, we consider the 
list of datatype definitions as given a priori. 


Expression: 

E 

= V 



1 c 

1 EE 

1 Xv i-4 E 

1 case E of P (->• E 

Pattern: 

P 

= V 



1 cP 

Variable: 

V 

= / 1 X 1 y 1 ... 

Constructor: 

c 


Figure 1.1: Syntax of our model language A 


Since in the present work we are only interested in creating a type system 
for this language, we omit a formal description of the semantics of A and 
instead refer the reader to the numerous treatments of the material, e.g. [18]. 

For brevity's sake, we'll exploit the left-associativity of function applica¬ 
tion and right-associativity of A-abstraction to omit unnecessary parentheses. 
Also, \x^ \y ^ E will be abbreviated as Xx y (->• E. 
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We will also assume every variable name to be unique. This can be easily 
ensured by appropriate 0 -conversions. 

1.2 Type systems 

What we expect of a type system for our language A is to statically, that is, 
without actually evaluating the expression, catch some class of nonsensical 
expressions. In contrast, a dynamic type system is one that only finds seman¬ 
tic contradictions while evaluating the expression in question. 

To reason about the semantics of a given A-expression without evaluating 
it, so-called types are attached to it and its subexpressions. A type system is a 
set of possible types and a collection of rules governing the way propositions 
of the kind "this given expression E has type r" can be decided. 

One can devise several type systems for A, differing in two important, and 
not at all orthogonal aspects. The first one is the kind of semantic errors that 
the type system can catch — the wider the range of detectable errors, the safer 
we can be that an expression accepted by the type checker is meaningful. The 
second one is the class of semantically correct expressions that the type system 
accepts. Ideally, we would want all semantically correct (i.e. meaningful and 
converging) expressions to be accepted by the type checker. 

To see why there is a conflict between these two requirements, consider the 
notorious class of divergent expressions, like the following canonical example[19]: 

:= (Ax 4n) (Ax' ha x' x') 

Of course, given that Turing-completeness[20] is a property of A we very 
much intend to keep, we cannot hope to detect errors of this kind in general[21], 

1.3 The HM type system 

The type system weTl devise for A in this chapter is the Hindley-Milner 
type system[4]. For example, given the set of datatypes T := {bool = 
true | false}, this type system can catch the error in the following expression: 

E := (A/ ha / false) true, 
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arising from the usage of x as some function with a domain in bool in the 
body of the A-abstraction, versus supplying a value of type bool for x. 

We detect this error by realizing that the expression is a function appli¬ 
cation with left subexpression Ax 4 x false being a function from "func¬ 
tions mapping bools to something else" to that something else (written as 
(bool -4 a) —> a), and the right subexpression being a value of type bool. 

Figure 1.2 gives the syntax and inference rules for the types that we want 
the type system HM to assign to A-expressions. Types are either type vari¬ 
ables like a in the previous example, function types (with a domain type 
and a codomain type), or concrete datatypes. Datatypes can also have type 
parameters. The function arity in figure 1.2 gives the arity (number of type pa¬ 
rameters) of type constructor T as a natural number, and is understood to use 
the information stored in the datatype context T that is preserved throughout 
the whole type checking process. 



Figure 1.2: Syntax of and inference rules for valid types of HM 


The Hindley-Milner type system, then, is a set of rules for deciding the 
validity of expressions. A given expressions E is accepted if it is typeable, 
that is, if the propositions T b r and 0 b E :: r are provable for some r 


9 




using the inference rules. We'll sometimes write b E :: r as shorthand for 

0 b E :: t. 

In this chapter, E is an expression of A and r is a valid type as defined 
in figure 1.2. Later, we will extend both A and the set of inference rules to 
support other features by allowing for somewhat different domains for E and 

T. 

Figure 1.3 on the following page shows the inference rules of HM. It uses a 
context T mapping variables to types to ensure consistent typing of variables. 

1.4 Observations about HM 

There are several things to note about these rules. The first is that a given 
A-expression can inhabit many types. For example, given the following ex¬ 
pression: 


id := Xx x, 

the statements "id inhabits the type bool -4 bool" and "id inhabits {a -4 0) -4 
(a -4 6)" and many more are provable. So it is natural to ask: what is the 
most general type that a given expression E inhabits? We'll say that the 
polymorphic type a = 'ia.r is the principal type of a given expression E if it 
fulfils the following requirements: 

• It is indeed a correct type of E, i.e. b E :: r 

• It is a generalisation of every other type: for all r', the statement b E :: r' 
holds if and only if f* e inst(cr) (see figure 1.4 for the definition of inst) 

It can be shown[22] that any typeable expression E has a unique principal 
type (up to renaming type variables and omitting superfluous type variables 
from a). For example, the principal type of id is Vet.ce -4 a. 

The second important thing to note is that some inference rules making up 
the system HM (notably, Abs and Inst) are not constructive in the following 
sense: consider, for example, the following derivation of the principal type 
Va.(a -4 a) -4 (a -4 a) for the expression A/ x 1-4 / (f x): 
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x :: 


(MonoVar) 


T h E :: a t G inst(cr) 
Y \~ E :: r 


(Inst) 


rh£::r'-»r r h P :: F 
rbFP :: r 


(App) 


T; (x :: F) h E :: t Th F 
T h Ax i-A E :: F — >• t 


(Abs) 


T h E :: T 0 
Pi :: T 0 H Fi r;Ti h Fi :: r 


P n :: To H r ; r n h E n :: t 
r h case E of Pi i—>■ Fi... P n (->• E n :: t 


(Case) 


T h T 

x :: 7 I (x :: t) 


(VarPat) 


cr) e T ffj-4-- > T n -> T't) e mst(cr) 

Ti H Ti ••• P n :: T n -\ Y n 
cPi...P n :: T t H Ti ;... ; T n 


(ConPat) 


Figure 1.3: HM inference rules for A 


^/t = t' dom 'P — a 
t' G inst(Vu.T) 


Figure 1.4: Inference rule for the inst relation 






where 


r 2 b f :: a- 


r 2 b fx :: a 


r 2 b f :: a - 


r 2 b f(fx) :: a 
T 1 b Ax^/ (fx) :: a- 


5 b A f x i ->•/ (f x) :: (a —>• a) —>• (a - 


T 1 = (f :: (a a)) 
r 2 = Ti; (x :: a) 


As we can see, the derivation is straightforward only once we know a 
good choice for and r 2 , which corresponds to choosing r' when applying 
rule Abs. However, coming up with the correct types when entering a A- 
abstraction is just the problem of type inference that we want to solve! 

Fortunately, the situation is not as bad as this circular-looking reasoning 
would make one believe, and we will later describe in detail the well-known 
algorithms W and M. that implement type inference by solving this problem. 
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2. Let-polymorphism 


In this chapter, an important and widespread extension of the language A 
and its typing rules are presented: recursive, polymorphic let bindings. 


2.1 The A let language 

Figure 2.1 shows syntax extensions of the A language presented in figure 1.1, 
with the changes highlighted. 


Expression: 

E 

= 

V 



1 

c 



1 

EE 



1 

Xv i —y E 



1 

case E of P (->• E 



1 

let D in E 

Definition: 

D 

= 

vP = E 

Pattern: 

P 

= 

V \ c P 

Variable: 

V 

= 

f 1 x I y 1 ... 

Constructor: 

c 




Figure 2.1: Syntax of A let 


The new construct let allows for local function definitions 1 . This is an 
important difference in our definition in contrast to usual treatments of the 
subject, which only allow variables to be defined inside a let. Since in this 
thesis we intend to arrive at practical results for reporting type errors, we 
choose this definition of let that is a lot closer to the facilities offered by real- 
life functional programming languages. 

Functions are defined using pattern matching on the arguments, like map 
Variables can be defined as functions with no arguments 
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in the following definition, with T = {[«] = nil | cons a [a]}: 

let map f nil = nil 

map f (cons x xs ) = cons (/ x) ( map f xs ) 

in map. 


2.2 Recursive definitions 

Recursion, as demonstrated by the previous example of map, is an explicitly 
desired property of let, in the sense that local definitions should be able to 
refer to themselves. 

The following example demonstrates a technique for transforming mutu¬ 
ally recursive definitions into straight recursion by combining the definitions 
into a single tuple; both expressions yield the infinite list (true, false, true, 

FALSE, ...)\ 

T := {(a, f 3 ) — (a, ( 3 ), [a] = nil | cons a [a], bool = true | false} 

mutual := let tick = cons true tock 
tock = cons false tick 
in tick 

flattened := let prof (x, y) = x 
prof (x, y) = y 

in let ticktock = let tick = cons true ( prof ticktock) 
tock = cons false (prof ticktock ) 
in (tick, tock ) 
in prof ticktock 

This transformation can be easily automated by detecting mutually recur¬ 
sive definitions (by searching for all strongly connected components of the 
variable reference graph). By avoiding mutual recursion, it is also enough to 
allow only a single function definition (with multiple patterns, of course) in 
one let, because multiple definitions can be transformed into nested lets in 
the order determined by the topological sorting of the aforementioned graph. 
We will use these observations in later chapters, when detailing type in- 
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ference algorithms for A let , by assuming singular recursive definitions in let 
without loss of generality, by presuming an appropriate transformation step 
before type checking. 


2.3 HM type inference for A let 

Here we extend the type system HM with additional rules to support the new 
let construct. First of all, just as the inference rule Case needed the rules 
VarPat and ConPat to collect the newly bound variables in a pattern, we 
need rules to collect the variables bound in a let: 


P 1 ::t 1 ~\T 1 ••• P n :: r n H T n 1:1^ .. .:\' n h K :: r 

r \~f Pi... P n = E ~\ (f :: Ti T n —>■ t) 

Figure 2.2: Typing rules for collecting let-bound variables 


Given the requirement for allowing recursion, the most straightforward 
type inference rule one can give for let is to require the newly bound defini¬ 
tions to be typeable in the very context that they define, and type the body of 
the let in the same context: 


r' = ri;...;r n 

rjFhPHr! • • • r ; r'h D n -\ r n 
r;r'h£::r 

r h let £>1 ... D n in E :: t 


(MonoLet) 


The actual rule Let, as shown in figure 2.3 on the following page, differs 
from this rule because we want let-bound variables to be polymorphic inside 
the body of the let. For example, the following expression is not typeable 
without let-polymorphism, because the two occurrences of id need to be as¬ 
signed the non-unifiable types bool -a bool and [cc] —>■ [a]: 


let id x = x in P (id true) (id nil). 


To achieve this, the types of let-bound variables are generalised (by adding 
an appropriate V quantifier) in the context of the body. Of course, for poly¬ 
morphic variables to be usable, we also have to add a new inference rule for 
polymorphic variables, that mirrors the Con rule, for instantiating polymor¬ 
phic types. 
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(PolyVar) 


(x :: a) e T rG mst(cr) 
r hx :: r 


r , = r i; ... ; r ft 

r; r h Pi h Pi • ■ ■ r ; r i- p„ h r n 

V" = {x :: cr |(x :: r) e T', a — gen(r, r)} 
T; r" h E :: T 

r b let L >1 • • ■ -Dn in E :: r 


Figure 2.3: New typing rules for A let 


(Let) 
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3. Type inference for 
Hindley-Milner type systems 


A type inference algorithm is one that, given an expression E and an initial 
environment r 0 , either returns a positive result of a type r such that T 0 b E : r, 
or a negative result of some error message about E not being typeable. As 
an added requirement, we also expect algorithms for HM to return, in the 
positive case, the principal type. 

Two important properties of type inference algorithms are soundness and 
completeness. A given algorithm is sound if its positive answer is always cor¬ 
rect, and it is complete if it returns a negative answer only when the given 
expression is not typeable in the given type system. 

3.1 Algorithm W 

Milner's original paper presenting the (let-polymorphic) Hindley-Milner type 
system[4] included algorithm W that computes the principal type of a given 
expression. The algorithm works by always assigning new type variables to 
the parameters of A-abstractions, and collecting type substitutions on the way. 
The type substitutions are generated by solving type constraints arising from 
applications. Somewhat later, Damas[23] proved algorithm W to be complete. 
The general form of W is the following: 

W(r,£)= 

where T : a type context, mapping variables to types 
E : the expression whose type we are to infer 
T : a substitution, mapping type variables to types 
r : the inferred type of E 
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Recurrences in the definition of W always refer to smaller subexpressions; 
thus, the definition is well-founded. 

We omit the definition of W for case and let expressions here, and only fo¬ 
cus on the core language of variables, function application and A-abstraction. 


3.1.1 Variables 


W(I'. x)—(0,r) 

if (x :: r) e T 

vy(r,x)=(0,{o'w^}T) 

if (x :: Va.r) E T 

where [3 new 



The inference rules for variable occurrences is simply a matter of looking 
up the variable in the type context T. Variables with polymorphic types are 
instantiated differently for every occurrence. Since a variable occurrence, by 
itself, imposes no type constraints, no substitution is required. 

3.1.2 A-abstraction 

w(r,Ax^£) = >t) 

where (\&,t) = W(T; (x :: (3),E) 

(3 new 

Inferring the type of a A-abstraction entails inferring the type of its body, us¬ 
ing an extended type context. The variable of the A-abstraction is inserted 
as a monomorphic variable into the context; recall that we assume all vari¬ 
able names to be distinct (by a separate scoping transformation before type 
inference), so there can be no conflicts when adding (x :: /?) to T. 

Constraints on the type of the argument can, of course, be imposed by the 
body of the A-abstraction. These constraints ultimately generate substitutions 
of the form (3 r', which is then applied to the left-hand side of the function 

type returned by W(T, Xx ^ E ) to produce the type t' —>• r. 
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3.1.3 Function application 


W(r, E F) = (f o f 2 O !, tf/3) 
where (^i,rj) = W(T, 1?) 

(^ 2 ,r 2 ) = W(^r,F) 

= U(^> 2 T 1 ~ ^2 —> /#) 

/? new 

To infer the type of applying the function E on the operand F, the type of both 
E and F needs to be inferred. The compatibility requirement r E ~ r F ->• r E f 
is a straightforward transliteration of the type inference rule App. 

Since both E and F may refer to the same variables, constraints arising 
from one can affect the other. This is captured by the fact that W recurses on 
F with a modified environment T|T. In the next chapter, we shall see how 
this is an important point with regards to reporting type errors. 

3.2 Algorithm M 

There is no clear origin of algorithm At, another type assignment algorithm 
for Hindley-Milner type systems; Lee and Yi presented a formal treatment of 
the by-then widespread folklore algorithm in [24], proving its soundness and 
completeness. Their paper also proves an advantage of M, which is that M 
stops earlier than W for non-typeable inputs. 

The basic idea behind algorithm At is that instead of the At function re¬ 
turning the inferred type of subexpressions, the expected type is passed to it 
as an argument. The well-foundedness of the recursion is, again, ensured by 
always recursing on smaller subexpressions. 


M(T,E,t)= 


where T : 

a type context, mapping variables to types 

E 

the expression to typecheck 

t : 

the expected type of E 

: 

a substitution, mapping type variables to types 
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3.2.1 Variables 


The inference rule for variables closely mirrors that of W: the type of the 
variable as stored in T is checked against the expected type from the function 
argument: 

M{T, x, t)—U(t ~ t') if (x :: r) G T 

At(T,x, t)=U{t ~ {a P}t') if (x :: Vu.t') G T 

where f3 new 

3.2.2 A-abstraction 

M ( T , Ax 1-4 E, t ) = ^/ 2 ° 'Fi 

where = U{r ~ cc -4 /3) 

:: vp,o). f;. 

ck, j3 new 

Since A-abstractions are always typed as n -4 t 2/ the expected type must 
have this schema as well. This is expressed by the first unification step that 
deconstructs r into an argument type a and a result type Jt Note that the 
results of this unification can impose additional constraints on the type of 
variables in T, which is why it is the substituted context TjT that is extended 
before recursing into E. 


3.2.3 Function application 



For the application E F to have type r, E must be of some type r' -4 r, and 
F of type t' . This connection between E and F is implemented in M. via the 
shared type variable /A 


20 






3.3 Unification 

The type constraint solver used by W and M. is not at all specific to these 
type inference algorithms: a simplified special-case version of the universal 
predicate resolution algorithm described in [25] is used to calculate the most 
generic unifier for a set of type equations of the form r ~ r'. Figure 3.1 shows 
the definition of U', this function is shared by all type inference algorithms 
presented here, including the compositional algorithm introduced in chapter 
5. 

Note that although the set of equations can grow when recursing, there 
is a simple tree measure of types with which the total measure of the set of 
equations is always strictly decreasing, thus ensuring well-foundedness. 


W(0) = 0 

U({a ~a}u£) = U(1 7) 

{ error: Infinite type if a e vars r 
U (£) o \l/ otherwise 

where = {a t} 

U({t ~a}ur)= U({a ~r}ur) 

U ({t —> u ~ t' — >• u'} U £) = li{£ U {r ~ t', u ~ w 7 }) 

U({T n ... r n ~ T t[ ... r' n } U £) = U[£ U {n - r|.r„ ~ <}) 

U({t ~ t'} U £) = error: Contradicting constraints 

Figure 3.1: Calculating a most generic unifier 
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4. Reporting and explaining 
type errors 


In this chapter, we take a brief detour to analyse the error reporting capabili¬ 
ties of W and A4. Problems discovered here will serve as our motivation for 
a compositional type system in the next chapter. 

4.1 Linearity 

Both W and M. infer the type of composite expressions by inferring one 
subexpression (in some sense, the "first" one) and using its results in inferring 
the type of the next one. They are linear in the sense that partial results are 
threaded throughout the type inference. 

For example, recall the definition of W for applications: 

W(r, FF) = (fo$ 2 o !, 

where (\&i,ti) = W(T,E) 

(tf 2 ,T 2 ) - w(^ir,F) 

4/ = 1A(^ 2pL rsJ 7”2 — y /?) 

(3 new 

It first recurses on the left-hand expression E in context T, and then uses 
the result of this inference, \Fi, to recurse on F. If E and F are both well- 
typed, but there is a contradiction between the two (by e.g. not agreeing on 
the type of a variable in T), this error will always be discovered, and reported, 
as a fault with F, even though F would be well-typed by itself. 
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4.2 Errors discovered linearly 

The effect of linearity on type inference is that certain subexpressions (those 
that are processed earlier) can have greater influence on the typing of other 
subexpressions. This is bad because it imposes a hierarchy on the subexpres¬ 
sions that is determined solely by the actual type checking algorithm, not 
by the type system; thus, it can lead to misleading error messages for the 
programmer. 

For example, consider the following program: 

T :={(«, # = (<*> 0 ), 

CHAR = 'A' | ... | 'Z' | 'a' | ... | 'z', 

BOOL = TRUE | FALSE} 

T 0 := {toUpper :: char -a char, not :: bool -a bool} 
test X x (->■ (toUpper x, not x) 

The critical part is the application of ((•, •) (toUpper x)) on (not x). W 
will first assign some type variable a to x, then solve the type equation 
a ~ char generated by toUpper x, yielding the substitution a char. This 
leads to T' = {x :: char} going into the second part of the tuple, generating 
the unsolvable type equation char ~ bool. Thus, the second part, not x, is 
what is reported to be not well-typed. 

We could have changed the order in which W traverses the subexpressions 
of function application (and as weTl see below, some implementations use 
this order), but that would have merely resulted in entering toUpper x with 
V = {x :: bool}, resulting in the unsolvable type equation bool ~ char. 

4.3 A survey of Haskell compilers 

Below is the output of some popular Haskell compilers demonstrating the 
above, when trying to compile the following program: 

test x = (toUpper x, not x) 

All three of them correctly discover the type error, but they all report it as 
though it would be a problem with one of the parts of the tuple per se, not the 
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combining of the two. 


• GHC[17] 6.12: The subexpression toUpper x is processed first. The 
error message shows x to be typed char. 

Couldn't match expected type 'Bool' 
against inferred type 'Char' 

In the first argument of 'not'.* namely 'x' 

In the expression: not x 

In the expression: (toUpper x, not x) 

• Hugs 98[26] seems to process application in the reversed order: not x 
is checked first, leading to an error in toUpper x: 

ERROR "test.hs":l - Type error in application 

*** Expression : toUpper x 

*** Term : x 

*** Type : Bool 

*** Does not match : Char 


• Helium[13] 1.6 gives the same result as GHC above. The output is more 
verbose, showing the inferred type of both the applied expression and 
the argument; but otherwise it presents the same judgement that the 
expression not x is at fault by itself. 


(1,29): Type error 
expression 
function 
type 

1st argument 
type 

does not match 


in application 
not x 
not 

Bool -> Bool 
x 

Char 

Bool 


4.4 Explanation of type judgements 

When the programmer is presented with an error message from the type 
checker, fixing the problem requires understanding the result of the type 
inference. The problem with linear type inference algorithms is that type 
judgements for subexpressions cannot be explained without reference to other 
subexpressions. 

Presented with the above error messages, the programmer might wonder 
why the expression not x is not well-typed. It certainly looks well-typed by 
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itself. Also, there is no apparent reason for the judgement x :: char, referred 
to in the error messages. Focusing on not x, the expression where the error is 
reported, gives no insight on the underlying problem. 

Showing the programmer the type context F = [x :: char} is not of 
much help, either. While it does explain the source of the type equation 
char ~ bool, the programmer is still left out in the cold about the actual 
problem: with this T, it is trivial to see that not x is not well-typed, but this 
only leads to frustration because now it is clear that the problem stems not 
from the expression reported by the type checker as the source of the error. 

4.5 Other aspects of type error reporting 

Of course, there are many kinds of type errors and many possible presen¬ 
tations of them. Here, we have focused on examples where linearity is of 
great hindrance, because this is what we intend to fix; [15] gives another great 
example. 

As for possible improvements of type checkers for HM, [14] presents a 
thorough overview of the challenges and solutions of reporting good type 
error messages while staying inside the conceptual framework of HM, and 
thus, linearity. 
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5. A compositional type system 


In this chapter, we present an alternative type system for the A let language. 
Its main distinguishing property is that it allows for a compositional type 
checking algorithm, in contrast to the linear nature of W and M.. As we'll 
see, this can remedy some of the problems discussed in the previous chapter. 

We define here a compositional type system as one where the type of 
subexpressions is not dependent on other expressions that are either above or 
beside it. Of course, this cannot be achieved in the framework of the Hindley- 
Milner type system; for example, consider the following expression: 

let id x = x in | Id] true, 

in which the type of the marked occurrence of id is very much determined by 
the type of its sibling expression true. Hence the need for not just another 
algorithm, but a whole alternative type system. 

5.1 Motivation 

A compositional type system assigns types to expressions independent of 
their surrounding. Following up on our previous example presented in chap¬ 
ter 4: 


T :={(«, # = («, P), 

CHAR = 'A' | ... | 'Z' | 'a' | ... | 'z' . 

BOOL = TRUE | FALSE} 

r 0 := {toUpper :: char — > char, not :: bool — > bool} 


test A x (->■ (toUpper x, not x), 
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we expect a compositional type system to assign meaningful results to the 
subexpressions toUpper x and not x, since both of these are well-typed by them¬ 
selves. Using this information, the programmer can then realize that the real 
cause of the error is ununifiable view of the two expressions on what the type 
of x should be; the programmer can then see both views and then decide how 
to fix the problem. 

Our implementation of the type system described in this chapter outputs 
the following error message for the program above: 

input/test.hs:1:8-25: 

(toUpper x, not x) 

Cannot unify 'Char' with 'Bool' when unifying 'x': 
toUpper x not x 
Char Bool 

x : : Char Bool 

Note that the type of toUpper x and not x is correctly inferred despite the 
problems with assigning a type to x; this enables type checking to go on, 
finding other problems in the same run. 

5.2 Typings 

The key to our compositional type system is the notion of typings[27]. A 
typing captures all of the constraints imposed by an expression on its envi¬ 
ronment. For example, for the expression / x y to be well-typed, we need / to 
be a binary function, and the type of its arguments must match that of x and 

y- 

Type of expression: / xy :: 7 

Constraints on variables: / :: a -A ->• 7 

x :: a 

y P 

We defined A let to only allow simple recursion: when an expression refer¬ 
ences a variable, it is either a function argument, a previously defined func¬ 
tion, or a recursive reference. The type of functions already defined cannot 
be changed by a usage site, so that case yields no constraints, and function 
arguments and recursive references are monomorphic. This means that the 
typing of an expression contains constraints only on the type of monomorphic 
variables. 
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Using the notation of [15], a typing, written Ah r, consists of a type envi¬ 
ronment A = {x :: Ti,y :: r 2 ,...} mapping variables to monomorphic types, 
and a type r. Our previous example / x y thus has typing {f :: a —>■ /3 —>• 7 , 

xv. a, y :: 0 } h 7 . 

5.3 Polymorphic and monomorphic variables 

As we have previously seen, the type environment part of a typing contains 
only monomorphic variables. Let-bound variables, however, are polymorphic, 
and only the type of their specific occurrence can be influenced by a usage site. 

Thus, we split the variables into two groups: polymorphic and monomor¬ 
phic. Polymorphic variables are associated with a typing, and that typing is 
instantiated at usage sites, yielding no additional constraints except those in 
the typing itself. Monomorphic variables are associated with a monomorphic 
type, and all usage sites of a monomorphic variable must agree on its type. 

The type of polymorphic variables is stored in the polymorphic environ¬ 
ment r = {f 4 Ahr,...}; this environment is extended by bindings in let 
expressions. Monomorphic variables are stored in the monomorphic envi¬ 
ronment A = {x :: r',...}. This environment is extended by every variable 
occurrence, and every expression unifies the monomorphic environments of 
its subexpressions. 

Why do we need to store typings in the polymorphic environment instead 
of just types? It is because the definition of a let-bound variable can refer to 
monomorphic variables, and thus its usage can impose additional constraints. 
Consider the following example: 

T := {char = ..., BOOL = ..., (a, ft ) = ..., [«] = ...} 

T 0 := {map i-A 0 b (a -» /3) -A [a] -A [/], toUpper not (->•...} 


test := A xs H- let xformf = map f xs 

in (xform toUpper, xform not) 

The typing of xform after the generalisation is {xs :: [a]} b (a —>• /) —>• [5]}. 
This typing can be instantiated to both {xs :: [char]} b (char -a 7 ) ^ [ 7 ] 
and {xs :: [bool]} b (bool -h5) a [5] for the two usages, and both maintain 
a constraint on the type of the monomorphic variable xs. 
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This also eliminates the need for explicit V quantification, because every 
type variable is renamable in a typing. The difference between a polymorphic 
and a monomorphic variable is that the latter contains itself in its typing, thus, 
its instantiated typing will still be monomorphic. 

In the example above, the monomorphic type environment of xform con¬ 
tains types in which a occurs, thus, it is not polymorphic in a. This is wit¬ 
nessed by the fact that all usages of xform must agree on the specific instanti¬ 
ation of a, but not on 

5.4 Unification of typings 

By now, it should be clear that the crucial step in the type system we're de¬ 
scribing is the unification of typings. We extend the unification algorithm 
from chapter 3 by allowing an additional parameter consisting of a list of 
monomorphic environments Ai,..., A n . Since monomorphic type environ¬ 
ments must agree on the type of all variables involved, from this list we gen¬ 
erate a set of type equations expressing this desired congruity: 


U{{ A 1; ..., A n }, E) = U{E' U E) 

where E' = {«(*) ~ A;(x) | i = 1... n, xe dom A,, a(x) new} 


5.5 Type system C 

The type system C we present here is a type system for A let based on [15]. 
Contrary to HM, it is constructive; thus, its inference rules can also be read 
as an algorithm, with judgement T; A b E :: t interpreted as a function 
mapping the pair of a polymorphic context and an expression (T, i?) to a 
typing A h t. Since the predicates of the inference rules always refer to 
smaller expressions, the recursion defined by this reading of the inference 
rules is not well-founded. 

We make no claims about the performance of C as a type inference algo¬ 
rithm. If performance turns out to be poor in real-world applications, one can 
run one of either M. or W to see if there are any type errors, and then run C 
only when errors are found. 
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5.5.1 Constants and variables 

Constructors impose no constraints on monomorphic variables. References 
to previously defined, and thus polymorphic variables import the respective 
monomorphic type environment. We instantiate typings by consistently re¬ 
naming type variables into fresh ones. 


(c :: t) e T 0 b t' = inst 0 b r 

(Con) 

T; 0 b c :: r' 

T(x) = A b t A' hr' — inst Abr 

(PolyVar) 

TjA'br :: r' 

Monomorphic variables are those that have no associated typings in the 

polymorphic type environment T. Such occurrences 
the newly-introduced monomorphic variable in A. 

are typed by recording 

x ^ dom T a new _ , T , , 

r , , (MonoVar 

T; {x :: a} b x :: a 


Note that this formulation doesn't detect out-of-scope references. Scope 
checking is assumed to have been done in a previous pass, because it is al¬ 
ready needed to flatten out let declarations into non-mutually-recursive par¬ 
titions. 


5.5.2 A-abstraction 

The variable of a A-abstraction is monomorphic in the abstraction's body. This 
means the polymorphic context T is not extended by the argument variable 
before descending into the body; instead, the type of the A-abstraction is de¬ 
termined by looking at the monomorphic type of the variable from the typing 
of the body. 
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The two cases correspond to A-abstractions with and without references to 
their argument. In the former case, the argument variable is removed from 
the typing of the body in the resulting typing, since different usages of the 
same A-abstraction don't have to agree on the argument type. 

Consider the following example: 

T := {bool = ..., (a, 0 } = ..., [ a ] = ...} 
idPair := let id = Xx (->• x in (id true, id nil). 

The inferred typing of x is {x :: a} b a; thus, the typing of id would be 
{x :: a} b a —>■ a: if x wasn't removed from the monomorphic environment. 
This would lead to the contradicting typings {x :: bool} b id true :: bool 
and {x :: [b] | b id nil :: [/?]; in effect, losing let-polymorphism. 

5.5.3 Function application 

The inference rule for function application consists simply of inferring the 
typing of the function and the argument, and unifying the two. However, 
behind this simplicity lies compositionality: unlike HM, there is no direction¬ 
ality and no flow of information between the descendings into E and F. 


T;Ai b E :: t' T; A 2 b F :: t" 

(App) 

T;Ab£F :: r 

where a new 


= U({ Ai, A 2 }, {t' ~ t" a}) 


A = ^Ai U ^A 2 


t = \l/a 



The combining operator A U A' is defined to be a union of two monomor- 
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phic environments, provided they agree on their common monomorphic vari¬ 
ables. Here, the two results Ai and A 2 are combined using the unifier substi¬ 
tution T, ensuring that TAi and TA 2 agree on their intersection. 


5.5.4 Case expressions 


The inference rule for case expressions is pretty straightforward. Patterns 
generate monomorphic type environments to allow for the necessary connec¬ 
tion between patterns and cases. Note that variables defined in patterns don't 
leak out; this is necessary for the same reason we removed the argument 
variable from the typing of A-abstractions. 


T; A 0 h E :: t 0 
A[ l-Px :: t{ T;A 1 b E l :: n 


A' n Y- P n :: r' n T; A n b E n :: r n 
T; A b case E of Pi H)■ E\... P n H)■ E n :: r 


(Case) 


where a new 

'P = U{{ A 0 , Ai, A [,..., A n , A(j}, {t 0 ~ t-, Ti ~ a \ i = 1... n }) 
A = 'I'Aq U |J (^A* \ dom A') 

r = \Pcfc 


The inference rules for patterns is basically the same as for their counter¬ 
parts in expressions. The differences arise only because pattern-bound vari¬ 
ables are always monomorphic, and because constructor patterns have to be 
fully applied. 
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a new 

{x :: a}br :: a 

(VarPat) 

(c :: T x y - >T n ^Tr)e 

T 

Aib Pi :: t{ ••• A n b P n 

:: tL 

A b c Pi ... P n :: (T t 

-- (ConPat) 

where ^ = U({Ai,.. . , A„}, {n ~ t[, .. 

• ,r n ~ r' n }) 

A = 'LAi U • • • U ^A n 



5.5.5 Let bindings 

The key step in the inference rule for let is the construction of the monomor- 
phic environment TA'lJTAo. Each definition is typechecked separately, using 
the original polymorphic environment. As we've shown before, this ensures 
monomorphic recursion by collecting recurrence constraints in Ai... A n . The 
substitution T 0 unifies the view on both the recurrence's type, and other, ex¬ 
ternal monomorphic variables (e.g. from an enclosing A-abstraction). 


r ; Ai b f Pi = Ei 

T;A n b fP n = E n 
r';A' b E :: r 

-=-=- (Let) 

T; A b let / P 1 = E 1 ■ ■ ■ f P n = E n in E :: 'Lt 

where a new 

= W({A 1} ..., A n }, (Aj(/) ~ a | i = 1... n} 

A 0 = \JVA i \{f} 

r' = r ; {/-^ A 0 b^ 0 «} 

^ = U({A 0 , A'}) 

A = 'LA' U 'LAo 

The newly-introduced variable / is removed from the resulting environ¬ 
ment, leading to let-polymorphism as we have seen previously. 
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The inference rule for individual definitions forces the inclusion of the 
currently-defined variable in the monomorphic environment, to communicate 
the type of the right-hand sides of the equations even when no recursion 
occurs. 


Ai b Pi :: t i 


A n b P n :: T n 

r, A' b E :: r 0 
T;Ab f P 1 ■ ■ ■ P n = E 


(Def) 


where A 0 = {f :: t\ r n —>■- t 0 } 

V = U{{A 0 ,A 1 ,...,A n ,A'}) 

A = (tf A 0 U A') \ (J dom A* 


The absence of mutual recursion, and the restriction of one variable bind¬ 
ing per let are exploited only to simplify the formal statement of the inference 
rule; the above definition is easily adaptable for languages like Haskell that 
directly permit mutual recursion. 


5.6 Principal typings, C and HM 

Previously, when discussing type judgements of the form b E :: r, we saw 
that a given expression can inhabit many types. The same holds for typ¬ 
ings as well: {f :: bool -a [bool] -A char, x :: bool, y :: [bool]} b char is 
a perfectly valid typing for / x y. 

Principal typings are defined in such a way as to relate C to HM: given an 
expression E and a polymorphic environment T, we say A b r is principal if 

• It is a correct typing of E, that is, T; A b E :: r 

• Every other, HM-correct typing is just a substitution away: if (P') v U A' b HM 
E :: t', then there exists a substitution T such that A' = TA and 
t ' = Tr. Here, (r) v denotes the polymorphic HM-environment cre¬ 
ated from a C environment by adding appropriate V-qualifiers to every 
type. 
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The algorithm directly constructible from C computes principal typings. 
Because of the definition of principal typings, a corollary of this is that every 
expression typeable in the system HM is also typeable in C ([28] via [15]). 
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6. Type class polymorphism 


In this chapter we extend HM with overloaded functions in the form of type 
classes. This extended type system HM K is a suitably close model of the type 
system of the Haskell 98 language. The next chapter presents the changes to 
the compositional type system C to support HM K in the same way vanilla C 
supports HM. 

6.1 Non-parametric polymorphism 

The polymorphic expressions we've seen in previous chapters had no way 
of depending on the actual types involved at a usage site. The polymorphic 
function map defined in section 2.1 on page 14, of type Vo, [3. (a — > /3) —>• [a] —>• 
[/l], acts in the same way for any choice of o and (3. 

However, sometimes it is desirable to reuse names without reusing defini¬ 
tions. For example, it is very convenient to have a function (=) :: o -A a -A 
bool that means different things depending on the actual types involved, so 
that we can use it as x = ' a ' or map f y = nil, but define it differently for 
characters and lists. 

Overloaded functions like (=) allow for generic definitions like the follow¬ 
ing: 


elem := let elem x nil = false 

elem x (cons y ys ) = (x = y) V (elem x ys ) 

in elem. 

But what should be the type of elem? It cannot be Vcc.cc —>■ [a] —> bool, because 
equality might not be defined for all types. Picking a single type for which 
we know equality exists, e.g. typing elem as char -a [char] -a bool, means 
giving up the whole "genericity" point. 
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What's needed is a way to express the middle ground between a V-quantified 
polymorphic type and a concrete type; one that expresses the additional re¬ 
striction that you can't choose any type for a, it has to have an associated 
definition of (=). 

6.2 Type classes and instances 

Instead of singular overloaded functions like (=) in the example above, many 
functional programming languages like Clean and Haskell 98 lump overloaded 
variable declarations into so-called type classes [29]. A type r is an instance of 
a type class if there are variables defined for that type corresponding to the 
declarations of the type class. 

For example, in Haskell 98, the type class Eq is a specification of two 
overloaded functions for a given type a, with types (=) :: a — >• a — >■ bool and 
(^) :: a —>■ a —>■ bool. Note that the type variable a must always occur in 
overloaded declarations of a class defined in terms of a, since otherwise there 
would be nothing to dispatch on. On the other hand, the variables declared 
to be overloaded don't need to be functions, they can be constants as well. 

In the specific example of Eq, defining one overloaded variable in terms 
of the other is a straightforward matter; for such cases, Haskell 98 allows 
default definitions of overloaded variables. In this thesis, we will simplify 
matters by not allowing default definitions. Since we are only interested in 
type checking, it doesn't matter where the actual definition of an overloaded 
function comes from. 

For interpreters and compilers, [16] describes a program transformation 
from a language with overloaded variables to one without them. 

6.2.1 Superclasses 

A type class can be defined to have other superclasses. If k' is a superclass of 
k, that means every type that is an instance of k also has to be an instance of 
k'. We will use the notation k < n! for the reflexive transitive closure of this 
relation. 
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6.2.2 Type class declarations 

To be able to define type classes, we would need to extend the A let language 
with new constructs. To simplify matters, just like we did with definitions of 
algebraic data types, we will assume all classes and instances to be known 
a priori. The datatype context T is extended to contain information about all 
classes and instances. In particular, the information stored in T about classes 
is: 


• List of type classes: The statement Ths holds if k is a type class. 

• Superclasses: given two type classes k and k', the statement T b k < k' 
holds if k' = k or k' is a (direct or indirect) superclass of k. 

The types of the actual overloaded variables are stored in T as polymorphic 
variables. If the variable v is declared to be an overloaded variable in class 
k a having type V/3.(9 r, then (v :: Vcn, [3.{k a} U 9 => r) is included in the 
initial T 0 . 

6.2.3 Instance definitions 

Types are not directly defined to be instances of a type class; instead, only 
type constructors can be made instances. Given a type class k and a type 
constructor T with arity n, and some type variables a k with k <n, the 

partially applied type constructor T .. .a k can be made an instance of k by 
supplying the definitions of the overloads declared in k. 

Note that this effectively means at most one instance for a given pair («, T ) 
because the type of the overloaded variables declared in k uniquely deter¬ 
mines the arity of the type constructors which can be instances of k. 

Since the definition of an instance may require the type arguments to be 
themselves instances of some other type classes, statements about instances 
are of the form T b {«i a:,,..... n m a im } => k (T ai,..., ak). 

6.3 Overloaded and polymorphic types 

With type classes, the type of the previously defined variable elem should 
express that it can inhabit the type a —>• [a] ->• bool if a is an instance of 
class Eq. This requires an extension of the type system HM; we will call this 
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extended system HM K . Figure 6.1 shows the syntax of types in HM K , with the 
changes compared to HM highlighted. 


Type variable: 

a 


Type constructor: 

T 


Simple type: 

T 

-ii 

Type class: 

K 


Overloaded context: 

0 

= kTt 

Overloaded type: 

P 

= (j> T 

Polymorphic context: 

9 

= ~K~a 

Polymorphic type: 

a 

= Vn.0 =>• r 


Figure 6.1: Syntax of types of HM K 


Using this syntax, we will write the type of elem as Va.{Eq a} =>- a —» 
[a] — y bool. This is an example of a polymorphic type in HM K . Much like 
polymorphic types in HM, it allows occurrences of elem to inhabit different 
type instantiations. 

The result of such an instantiation is an overloaded type recording the re¬ 
quired instance context. For example, by instantiating a to [/3], we get the 
overloaded type {Eq [/!]} =#■ [ 5 ] —>• [[/?]] —>• bool. The predicate Eq [/ 3 ] may 
or may or may not be a satisfiable, depending on whether [] is an instance of 
Eq. For example, it may be the case that there is a universal instance of Eq [] 
(i.e. T b Eq [/!]), in which case the predicate can be resolved into the empty 
polymorphic context, as in {} =>- [/!] ->■ [[/!]] ->• bool. 

A more realistic example is to define equality on lists using equality on 
elements, expressed by the instance proposition T b Eq jd =>- Eq [/?]. In that 
case, the predicate of the overloaded type {Eq [/!]} => [d] —> [[/!]] ->• bool is 
resolved into {Eq /3} => [/3] —>■ [[/3]] —>■ bool. 

The following figure shows the definition of the predicate resolution oper¬ 
ator cj) -» 9: 
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Note that after the predicates in an overloaded context are resolved, the 
result is always a polymorphic context. 


6.4 Inference rules for HM K 


Compared to HM, the most fundamental change in the inference rules is the 
addition of a local instance environment $. It is a set of overloaded predicates 
like (f) and allows type inference rules to be formulated on simple types. 

There are two ways to move between simple types, overloaded types and 
polymorphic types: Inst instantiates polymorphic types in some local in¬ 
stance environment into simple types in an extended environment, and Over 
simplifies $ by moving predicates from the environment to the overloaded 
type. 


T, $ \~ E :: a (j) => t G inst(cr) 
T, $ U (j) b E :: t 


(Inst) 


T, $ U (j) h E :: r 
LfhS :: (j) => t 


(Over) 


6.4.1 Constructors and variables 


The inference rules for constructors and variables are direct transliterations 


of the rules of HM. Note that occurrences of monomorphic (overloaded) vari¬ 
ables require the local instance environment to contain the necessary predi¬ 
cates. 


(c :: 9 =>• t) E T a = vars r 
T,$hc:: Va.0 => t 


(Con) 


(x :: (/) t) G T 
r, $ U (j) b x :: t 


(MonoVar) 


(x :: a) G T 
r,fhx :: a 


(PolyVar) 
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6.4.2 Application, A-abstraction and pattern matching 


These too are directly derived from the respective rules of HM. Patterns have 
overloaded types as opposed to simple types because the type signature of 
constructors can contain predicates. 


T, $ h P :: t 1 — ¥ T T, $ b F :: r' 

rvi> h E F :: t 


(App) 


(r;(x :: E :: r Thr' 

T, $ b Ax (-)• E :: r' —>• r 


(Abs) 


Pi : 

: </>i => t 0 H Pi 

T b 0i □ $ 

r,$ h 

ruri,$ h 

E : 

E l 

■ To 

:: t 

P n : 

:: <t>n => t 0 H T n 

T h 0 n fc 4> 

rur„,$h 

E n 

:: r 


r, $ b case E of P\ (->• E x ... P n i-A E n :: r 


(Case) 


Thr 

x :: 0 => r H (x :: r) 


(VarPat) 


(c :: cr) G T 

(0 Ti —>• •••—»■ T n —>• T t) G inst(cr) 

T h 0 C $ 

Pi :: 0! HTi ••• :: 0 n =► T n H T n 

cP 1 ...P n :: 0 U 0i U • • • U 0 n ^ T t H Ti U ... U T n ( ConPat ) 


Here, the judgement T b 0 □ 0' on overloaded contexts is defined to be 
true if for every predicate k t in 0 , there is a subclass k' < k such that k't is 
in c t 


6.4.3 Let bindings 

In HM, let-bound variables are monomorphic in recurrences, and their type 
is generalised for the body of the let. Similarly, in HM K recurrences are typed 
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with overloaded types, and the generalisation results in a polymorphic type. 

Pi :: 4>i =>n HTi T b fa £ </> 

P n :: (f) n ^ Tn ~\ T n T h <f> n C 4> 

r U Ti U ... U r n , $ h E :: 6 =>• r 

_ IDefI 

r, $ b/ Pi... P n = £ H (f :: 0 =► n ->• ... ->■ t„ ->■ r) V ’ 

r = r i; ... ; r n 

r u r, $ b d 1 h r x • • • r u r, $ h D n h r n 
T" = {x :: o- | (* :: p) 6 Y'.a - gen(T,p)} 
rur",$h£ :: r 

r,$b let £>!... a, in£ :: r (LET) 

An important aspect of the type generalisation a = gen(T, p) is checking 
for ambiguous predicates: for every polymorphic predicate k (3 of the poly¬ 
morphic type Va.6 =>• t, the type variable (3 must occur in r. 

To understand this requirement, consider the following expression: 

T := { [cc] = • • •, (a, (3) = ..., (a, f3, 7 ) = ..., char = ..., 

Textual} 

T 0 := {show :: \/a.Textual a => a ->• [char \,read :: Ma.Textual a = 4 > [char] -a a] 

let test 1 x = read (show x ) 
test 2 x = show (read x) 
in ( testi , test 2 ) 

Here, the type of the two let-bound variables, after generalisation, are: 

testi ■■ Vn, (5.Textual a, Textual (3 => a ^ (3 
test 2 :: Va.Textual a => [char] -a [char] 

The inferred polymorphic type of test 2 fails ambiguity checking, because there 
is an instance predicate for the type variable a, but a does not occur in the 
type [char] —>• [char]. If we were to allow such polymorphic types, then 
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there would be nothing to dispatch on whenever test 2 is invoked — in other 
words, no way to resolve the calls to the overloaded functions read and show. 


6.5 Algorithms for HM K 

HM K is very much like HM in that type inference seemingly requires pre¬ 
science in the application of rules Inst and Abs. Also, any number of pred¬ 
icates can be moved from the local instance environment into the inferred 
overloaded type in Over, but only one choice leads to an unambiguous gen¬ 
eralised polymorphic type when applying rule Let. 

Since instance predicates can only arise from the usage of overloaded vari¬ 
ables, the bottom-up algorithm W can be easily adopted for direct type in¬ 
ference of A let in HM K . Other approaches such as [29] present translations 
of expressions into languages where implementations of the basic HM is suf¬ 
ficient to do type inference. The linearity argument presented in chapter 4 
applies to both methods. 
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7. Compositional type checking for 
type class polymorphism 


In chapter 4, we have demonstrated a limitation of linear type systems when 
it comes to explaining type errors. Compositional type systems, like the one 
described in chapter 5, can give better explanations because it becomes mean¬ 
ingful to argue about the type of subexpressions. 

Better explanation of type errors is useful for the working programmer — 
if it applies to a programming language with real-world use. The language 
A let with the type system HM K presented in chapter 6 is a good enough model 
of the functional programming language Haskell 98 so that practical results 
applying to Haskell can be derived from its analysis. 

Therefore, in this chapter we extend the type system C to allow for type 
class polymorphism, resulting in the type system C K that we've used to im¬ 
plement a compositional type checker for Haskell 98 (see the appendix for 
details on the implementation). 

7.1 Class predicates in typings 

The type system C presented in chapter 5 is based on judgements of the 
scheme T, A b E : r, where T is the polymorphic environment passed down, 
and A is the monomorphic environment collected from subexpressions. 

There are two apparent ways to include class predicates in the typing 
A b t. One is to use either overloaded or polymorphic types instead of a 
simple type, and the other is to include predicates in A. 

The problem with using an overloaded or a polymorphic type on the right- 
hand side of a typing (i.e. by allowing typings of the scheme A b p or A b a) is 
that class predicate constraints should propagate independently of the actual 
usage of overloaded variables. 
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For example, consider the following expression: 

T := {Textual} 

r 0 := {show :: V a. Textual a => a ->• [char]} 
idText := Xx i-a let s = show x in x. 

Using the inference rules of HM K , we can infer the principal type V a. Textual a =>• 

a —> a: 


T' h show :: V a. Textual a => a [char] 

T' h show :: Textual a => a -A [char] 

T', $ h show :: a —>• [char] F, $ h i :: a 

T', $ h show x :: [char] 

r, $ h s = show x H {s :: [char]} U, $ h x :: a 

T, $ h let s = show x in x :: a 
T 0 , $ h Ax let s = show xinx :: a -A cc 
T 0 b Ax (->• let s = show xinx :: Textual a =>• a —>• a 


with r = r 0 ; {x :: a) 

F' =T';{s :: [char]} 

$ = {Textual a} 

As we can see, the definition of s is enough to constraint the type variable a, 
without s actually occurring anywhere. 

Because of this need to make instance requirements introduced by vari¬ 
able definitions independent of variable usage, we record class predicate 
constraints generated by subexpressions and pass them around just like the 
monomorphic environment A. Type instantiation then affects the whole of A 
and this instance environment 0 in unison. 

Overloaded contexts only appear in intermediate steps of substitution: if 
ol t is applied to k a, the resulting overloaded predicate k t is immediately 
resolved (using the same resolution operator <j) -» 6 as used by HM K ), and 
the resulting polymorphic predicates are simply combined (with redundant 
superclasses removed) into the substituted instance environment 0'. We will 
denote this substitution-resolution-combination with the + operator. 
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7.2 Inference rules 


The inference rules of C can be adapted to handle class predicates in a straight¬ 
forward manner. We omit lengthy explanations and let the rules speak for 
themselves. 

7.2.1 Constants and variables 


(c :: 6 => t) E T 0; 0 h r' = inst 0; 0 h r 

(Con) 

T; 0; 0 h c :: r' 

T(x) = A; 0 h r A'; 0' h r' = inst A; 0 h r 

r ; A';0'hx :: r' 

(PolyVar) 

x 4 dom T a new ... T T . 

—- r —- (MonoVar) 

T;{x :: a};0 h x :: a 



7.2.2 A-abstraction and function application 


T,A;Q\-E :: r (x :: t') e A 
T;A\x;@l- Asi E :: r' —$■ T 


T;A;0l-TJ :: r x ^ domA anew 
T; A; 0 h Xx (->• E :: a —t 


(Abs') 


T;A 1 ;Q 1 \-E :: r' T; A 2 ; 0 2 h F :: r" 
T;A;0h E F :: r 


(App) 


where a new 

^ = U({ Ai, A 2 }, {t' ~ t " —>■ a}) 
A = ^Ai U ^A 2 

0 = ^r0j + ^© 2 

r = \l/a 
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7.2.3 Case expressions 


T; A O ;0 O t" E :: r 0 
A';0i h Pi :: T; A i; 0! h E 1 :: n 


a;;©; PP n :: r' n r ; A n ; 0! b E n :: r n 
T; A; 0 h case P of Pi i-A Pi ... P n i-A E n :: r 


(Case) 


where a new 

'P = U({ A 0 , Ai, A' 1; ..., A n , A(J, {r 0 ~ r-, Tj ~ a | i = 1... n}) 
A = ^A 0 U |J (\PAj \ dom A') 
r = 'Pu 

0 = 2^0* + tf©') + ^0 O 


_ a new_ 

{x :: a}; 0 h x :: a 


(VarPat) 


(c :: 9 t x ->■- f r n -A P r) e T 

Ai;0i bPi :: r( ••• A n ;0 n bP n ::< 
A;0bcPi...P n :: $(Tf) 

where = U{{ Ai,..., A n }, {n ~ r(,..., T n ~ r^}) 
A = Ai U • • • U ^A n 


(ConPat) 


0 = ^ + ^0 1 + ... + ^0 n 


Note that although pattern-bound variables are removed from the monomor- 
phic environment A in rule Case (which is exactly the same behaviour as C), 
the class predicates generated from patterns are collected as-is from the pred¬ 
icate environments 0'. 
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7.2.4 Let bindings 


TjAi;©! b f Pi = Ei 

r ; A n ;0 n b fP n = E n 
r'jA';©' b E :: r 
Unamb( 0 o , A 0 b To) 

T; A; 0 b let / Pi = El ■ • - / P n = E n in E :: 'Lt 
where a new 

*0 = ■ ■ ■, An}, {Mf) ~ o | i = 1 ■ • • n} 

T 0 = 

©O = E^O0i 

r' = r ; (f ^A 0 bT 0 > 

=W({A 0 ,A'}) 

A = vPA' U ^A 0 
0 = ^0 O + ^0' 

A i; ©! b Pi :: n 

A„; 0 n b P n :: T n 
r, A'; 0' b E :: t 0 
r ; A;0 \-f Pi ■ ■ ■ P n = E ^° EF ^ 

where A 0 = {f :: t% r n —>■ to} 

^ = W({A 0 ,A 1 ,...,A n ,A / }) 

A = ('I' A 0 U ^ A') \ (J dom A * 

0 = ^0. + 0 O + ^0' 


(Let) 
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7.3 Checking for ambiguous class predicates 

An important point of HM K is that the class predicates in a polymorphic type 
can only refer to type variables that occur in the type itself; for example, the 
type Textual a => [char] is not a valid polymorphic type because a doesn't 
occur in [char]. As we have seen, this rule is enforced by the application of 
gen in rule Let. 

However, there is no explicit type generalisation step in C, and class predi¬ 
cates are not associated with types. But there is a point when the polymorphic 
environment T is extended into T' by adding the typing of the newly-defined 
variable, 

eo = X>oBi 

r' = r ; {f ^ A 0 b ^ 0 n}, 


where we can check that usages of / will yield type equations that necessarily 
fix all type variables occurring in class predicates by requiring the following 
property Unamb: 

Unamb(0, A h r) := V(/c a) e 0 : a G vars rVa G [J {vars r' \ (x :: t') e A} , 

which can be seen in the inference rule Let. 
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Conclusions 


We have presented two type systems for the language A let , a practical model 
of real-life functional languages like Haskell or Clean. One is the well-known 
Hindley-Milner type system, the canonical type system for let-polymorphic, 
A-calculus-based languages; the other is a compositional type system based on 
typings that allows for better error reporting precisely by being compositional. 

By extending both type systems with type class polymorphism, a form of 
ad-hoc polymorphism, we arrive at the feature set of the Haskell 98 program¬ 
ming language. An implementation of C K can leverage all the advantages of 
compositional type inference presented in chapter 4, to report type errors in 
real-world Haskell 98 programs. Appendix A contains notes on our reference 
implementation. 


Future work 

The Glasgow Haskell Compiler (GHC) introduces many type system exten¬ 
sions to Haskell 98, some of which directly concern type class polymorphism[30]: 

• Multi-parameter type classes 

• Functional dependencies [31] 

• Flexible contexts & undecidable instances[32] 

• Flexible & overlapping instances 

A natural way to follow up on the present work would be adding support for 
these type system features to the compositional type system C K . 

On the practical side, our implementation takes some shortcuts and doesn't 
support some features of Haskell 98, most notably the module system, record 
types and the do-notation. A future revision of the implementation should 
fix these omissions to enable real-world usage. 
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A. Implementation notes 


As an illustration of the type system C K , we have created an implementation 
for the Haskell 98 programming language. This implementation, named Tan- 
doori, is available under the terms of the BSD license from http: //gergo. 
erdi.hu/projects/tandoori/. 


Using GHC as a basis 

The modular design of the Glasgow Haskell Compiler (GHC) enabled us to 
reuse the implementation of the "boring parts" of writing a type checker for 
Haskell. Tandoori is inserted into the compiler pipeline replacing the regular, 
Hindley-Milner-based type checker. This way, we can use the source code 
parser and the reference resolver from GHC. The latter also sorts definitions 
via dependency analysis, so its output is already more-or-less in the simplified 
format that we used when discussing A let . 

When we started work on Tandoori, the latest stable release of GHC was 
version 6.10. Adopting the codebase to GHC 6.12 only involved changing the 
topmost calls to the parser and the resolver since the output format of these 
steps was unchanged. 


High-level design 

Tandoori uses an Error/Reader/Writer/State monad[33] to thread state and 
results throughout the type inference: 

• The Error and the Writer part are both used for collecting type errors. 
Wherever there is a sensible, most generic default to use as the result of 
type inference, errors detected in that part are tunnelled into the Writer 
and type inference goes on with the default results. This allows us to 
detect multiple errors in one go. 
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• The Reader part contains information on data types, classes and in¬ 
stances (the T part of C K ), and the polymorphic environment for the 
current scope (T). We also store the source code location of the currently- 
analysed subexpression; this information is used in error messages. 

• The State part is a simple infinite supply of type variables, used wher¬ 
ever the inference rules call for a new unique type variable. 

The actual sequence of events in the type checker is as follows, with items 
marked * implemented by GHC: 

1. * Parse source code 

2. * Resolve references, sort and group definitions using dependency anal¬ 
ysis 

3. Collect data type definitions 

4. Collect class declarations, build superclass graph, calculate the < rela¬ 
tion on classes 

5. Collect instance declarations 

6. Type check variable definitions, record polymorphic types group-by- 
group in the order given by step 2 

7. Type check instance definitions 

Note that type class instances are processed twice. The first run merely 
records the existence of instances, and this information is used when type 
checking variable definitions. Instance definitions are only checked after the 
type of all defined variables have been inferred, since instance definitions can 
contain references to arbitrary top-level variables. 


Known limitations 

We have taken some shortcuts and omitted some features in Tandoori that 
would be straightforward but laborious to implement while giving no new 
insight. Among these are: 

• Module inclusion, implicitly including the Haskell Prelude 
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• Record data types 

• Do-notation 

• Guards 

Hopefully, the community will take up Tandoori and a future revision will 
address these points, leading to a compositional type checker that can enjoy 
real-world usage. 
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